I started this change trying to keep the IMcpServerBuilder in the ModelContextProtocol.Core package even after removing these dependencies, and while this is technically possible, it comes with too many downsides. Some of these we already knew, like the fact that anyone using AddMcpServer would still have to manually run the server (possibly via their own hosted service) after they built the ServiceProvider/Host.

However, the biggest issue, and the one that made me step back and reevaluate the approach was that the IMcpServer that gets registered by methods like WithStdioServerTransport via AddSingleSessionServerDependencies would not get any options configured using the options pattern unless someone knows to manually set up a new IMcpServer registration to read from IOptions<McpServerOptions>.

I considered keeping AddMcpServer(this IServiceCollection services, Action<McpServerOptions>? configureOptions = null) in the ModelContextProtocol package and just removing the configureOptions parameter. It'd then be possible to just add an overload in the AspNetCore package that does take configureOptions, but that would make things worse in my opinion. This would mean that builder.Services.Configure<McpServerOptions>(options => { }) would only work if you called the overload in the AspNetCore package which I think would be extremely confusing.

As ModelContextProtocol.TestServer demonstrates, you can still write a stdio server with just the ModelContextProtocol.Core package, so I do like this change over removing the server completely from the core package. However, I do realize that it's far less convenient to configure a stdio server without the IMcpServerBuilder, and people writing stdio-only servers likely won't want the AspNetCore framework reference.

The current iteration of this PR introduces a ModelContextProtocol.Core package that trims out the hosting and options dependencies from the existing ModelContextProtocol package. The new ModelContextProtocol depends on the Core package and exposes the same IMcpServerBuilder builder APIs as before. is basically the same as what ModelContextProtocol was previously and depends on the ModelContextProtocol package as it is in this PR. So we'd have three packages:

• ModelContextProtocol.Core
  • Depends on Microsoft.Extensions.AI.Abstractions
  • Depends on Microsoft.Extensions.Logging.Abstractions (and thereby M.E.DI)
  • Depends on System.Net.ServerSentEvents
• ModelContextProtocol
  • Depends on ModelContextProtocol.Core
  • Depends on Microsoft.Extensions.Hosting.Abstractions (and thereby Options, Diagnostic.Abstractions, etc...)
• ModelContextProtocol.AspNetCore
  • Depends on ModelContextProtocol.Hosting
  • Depends on Microsoft.AspNetCore.App FrameworkReference

This possibly helps address some concerns about dependency bloat for clients raised in #369 @KrzysztofCwalina.